IBIS Macromodel Task Group

Meeting date: 16 July 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:               * Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.
  
-------------
Review of ARs:

- None.
            
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the July 9th
meeting.  Dian moved to approve the minutes.  Michael seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220 update:
Yifan reviewed a presentation on the latest work related to BIRD220.  She first
discussed some of the questions and feedback from IBIS ATM on BIRD220.
1.  Will it affect [Composite Current]?  No, this proposal does not alter any
power-aware IBIS keywords.  It is only focused on modifying the Ku(t) and Kd(t)
scalers, which control the output current.
2.  Will time-averaged supply voltage noise affect the driver delay?  The
results will be checked and verified against transistor-level models.

Yifan also noted that the new proposed extraction process is simpler, and the
new proposal can cover a wider range of supply voltage deviations.  These
changes also address feedback from ATM reviewers.

Yifan reviewed the current limitations of IBIS.  She said that even power-aware
IBIS models can't reproduce the shifts in the rising/falling edges caused by
variations in the power supply.  IBIS's existing Ku(t) and Kd(t) scalers can
reproduce the edge rate changes and DC level shifts of the output stage in
response to supply variation, but they do not capture the edge shifts that occur
in the pre-driver chain.

The initial BIRD220 proposal introduced two additive terms to the existing Ku(t)
and Kd(t) equations.  These terms are linear and second order functions of the
difference between the time averaged power rail voltage Vcc(t) and Vcc nominal.
This approach had limitations and stability issues as the time averaged Vcc(t)
deviated further from nominal.  The linear and second order terms started to
dominate the K(t) equations and introduce non-physical oscillations in the
edges.

Yifan introduced a proposed new approach that no longer uses the additive terms.
Instead, the new approach directly computes a time shift to be applied to the
existing Ku(t) and Kd(t).  That is:
  Ku(t) = Kuo(t + delta V * DC_Jitter_Sensitivity)
where Kuo(t) is the time varying coefficient for the nominal Vcc0 case,
delta V = (time avg value of Vcc(t) since the last transition - Vcc0),
DC_Jitter_Sensitivity = jitter sensitivity in s/V.

In addition, to model non-linearities in DC Jitter Sensitivity as the range of
voltage variations increases, Yifan proposed that the new sensitivity keyword(s)
could contain a table of DC Jitter Sensitivity values at different voltage
deviations from Vcc nominal.

Arpad noted that the current BIRD220 provides a single value for
DC Jitter Sensitivity (one for the rising edge and one for the falling edge),
but the new proposal adds a table of values to address non-linearities.  Yifan
agreed.  Randy noted that several years ago he had presented some data in ATM
for a DDR5 device.  He recalled that Jitter Sensitivity was reasonably linear
over about 50 to 100mV.  Outside that range it became more non-linear, but he
said this is likely very dependent on the technology and also on the Vcc
nominal at which you start.

Randy suggested that the Jitter Sensitivity should probably be provided for the
normal pvt (process, voltage, temperature) corners.  Arpad suggested separate
rising and falling keywords, each of which would contain 4 columns (voltage,
typ, min, max) for the Jitter Sensitivity.  He said this would be consistent
with the I-V keywords, for example.

Fangyi asked for confirmation that the A(t) and B(t) terms were no longer in the
new proposal (A(t) and B(t) are the coefficients of the linear and second order
additive terms).  Chulsoon noted that equation was presented in the original
BIRD220 to provide the derivation, but it was not really part of BIRD itself.
He confirmed that those equations will not appear in the new proposal.

Fangyi noted a non-monotonic dip in Ku(t) in the middle of the edge in some of
the validation and comparison plots (slide 15).  He asked whether that dip was
physical.  Yifan and Chulsoon noted that the dip appeared in the original Ku(t)
itself, prior to the Jitter Sensitivity modifications.

Ambrish asked whether both rising edge and falling edge tables were required.
Yifan said they expected to require both.  Chulsoon noted that if a buffer is
truly symmetric then you could assume the falling edge is an inverted version of
the rising edge.  However, the buffers they had studied were not symmetric in
this way.  Chulsoon said we could consider an option to only provide one table,
but he thought the model maker could simply duplicate the table and provide
both.

Kinger asked why the keyword specifically has "Pre-driver" in its name.  Randy
said this proposal is intended to capture delay effects introduced by the pre-
driver.  Yifan and Randy reviewed the "current IBIS limitations" slide and noted
that slew rate changes and DC levels from the final stage were already captured
by IBIS.  Arpad noted that IBIS has I-V data for the output stage, and this can
be scaled with respect to supply variations by the ISSO PU and ISSO PD keywords.
That only changes the impedance (DC levels).  The edge rates come from the V-t
waveforms, but the V-t waveforms are used to compute multiplicative scalers to
the I-V data and don't provide the edge's shift in time.

Kinger asked why we need to worry about such large variations in the supply
voltage.  He said typically +-10% is all you see.  Anything outside of that, the
chip probably won't work anyway.  Randy agreed but said the table allows the
model maker to provide data over any range they want.  Randy noted that ISSO
tables also provide data over a very wide range, much of which will likely not
ever be used.  Chulsoon said it doesn't hurt anything to give the model maker
the option to provide data over a wide range.  He noted that the CMOS driver
they had been studying is fairly linear, but he had seen papers on much more
non-linear drivers.  He said he thought it was better to cover a range to help
model non-linear behavior.  Kinger said that a table to help cover non-linear
behavior was fine with him.  He just wondered how wide a range we really
needed to cover.  Randy said the range over which the data is provided is
entirely up to each model maker.  IBIS doesn't have to specify any range.

Randy and Arpad said this new proposal looked like a big improvement.  Arpad
asked what the next step would be.  Chulsoon and Yifan said they could update
the BIRD and prepare a BIRD220.1 draft for the next meeting.

- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan: Prepare a draft of BIRD220.1 and send it to the ATM list.

-------------
Next meeting: 23 July 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
